The attached patch to the qemu emulation of the pcnet hardware fixes
authorkaf24@firebug.cl.cam.ac.uk <kaf24@firebug.cl.cam.ac.uk>
Sun, 26 Mar 2006 10:39:04 +0000 (11:39 +0100)
committerkaf24@firebug.cl.cam.ac.uk <kaf24@firebug.cl.cam.ac.uk>
Sun, 26 Mar 2006 10:39:04 +0000 (11:39 +0100)
commitac58fadfa5bfd652bd8c85a5e68b11309886d167
tree2d1ac2baa5797382ec7675623ef7f4308d6e2c9f
parent9c6543d4af04e8bbbdc879164a60cf86e20553ee
The attached patch to the qemu emulation of the pcnet hardware fixes
several problems.  It will now only read and write a transmit or receive
descriptor once.  It will correctly handle transmitting frames with more
than two fragments.  It will discard oversize frames instead of
corrupting memory.  I have tested all the changes I have made and even
seen an improvement in receive performance from 1.7MB/s to 3.3MB/s.
Your mileage will vary.

The code could be simplified if multi-fragment frames were deleted.  It
appears that both Linux and Windows XP don't use fragmented frames.

The mac crc computation code was deleted, since it has never been used.
The code was checking the wrong bit in the control register.

I tested type 3 descriptors by modifying the linux pcnet32 driver, but
did not see any difference in performance over type 2 currently used.

I have not made any change to type 0 (16-bit) transmit/receive
descriptors as I have no way to test the changes.

Please test this as soon as possible, as I will be on vacation next week
and in a class the following week.  I will check email from time to
time, but my ability to make changes to code will be greatly dimished.

One other thing I noticed in my testing, is that if I tell a linux domU
to reboot, it will reboot but not have any pcnet32 device after
rebooting.  By doing a shutdown, xm destroy and xm create, I was able to
get around that problem.

Signed-off-by: Don Fry <brazilnut@us.ibm.com>
tools/ioemu/hw/pcnet.c
tools/ioemu/hw/pcnet.h